HyperHIT
Volume Number: 7
Issue Number: 6
Column Tag: HyperChat
HyperHit
By Paul Whittington, Susan Venn, Griffin Software, Inc.
HyperHIT: A HyperCard-Friendly Database Engine
[Paul Whittington holds a Bachelor of Science degree in Electrical Engineering
and a Master of Management degree. He has been developing software since 1974, and
started Griffin Software with Susan Venn in 1985, to develop software for the
Macintosh.
Susan Venn holds a Bachelor of Science degree in Mathematics, and an MBA. She
became a software consultant in 1980.
In addition to being the developers of HyperHIT, Susan and Paul provide technical
support for the product family.]
HyperCard is a wonderful development environment for the Macintosh. It
provides an easy way to take advantage of a graphical user interface, without having to
become a Macintosh toolbox expert. Developing and modifying applications is easy,
because HyperCard is interpreted. It directly supports buttons and menus. It
introduces users to some concepts of object programming and encourages
“non-programmers” to develop programs (after which they are programmers,
whether they like it or not).
What HyperCard is not is a database. True, you can do some database functions
with HyperCard. By using the card marking feature of HyperCard 2.0, you can select,
sort, and print subsets of data. You can find information fairly quickly using
HyperCard’s “Find” command. But you cannot easily develop different views of data, or
manage non-homogeneous data without duplicating data and using multiple stacks.
For example, if you want to keep recipe cards in a stack, it is very
straight-forward. You simply substitute a HyperCard card for an index card. Finding a
recipe based on a style of cooking or a main ingredient is very simple. It is much faster
and simpler than trying to do the same thing with index cards.
Now let’s complicate the application. Let’s say that you want to not only keep the
recipes, but also keep track of your food inventory. You want to keep track of which
foods were served when, in order to provide variety. You might also want to correlate
this information with your diet and weight database. Finally, you want to have the
application automatically print a shopping list on demand, based on current inventory
levels and next week’s menus.
You say you can do this in HyperCard, no sweat. Good for you! I would fall back
on a database program to do this. Better yet, I would use a database engine which uses
HyperCard as a front-end.
There is no one database product that is the best choice for every application.
Each has its strengths and weaknesses. Most database engines used with HyperCard
were retrofitted to allow you to access them from HyperCard. The result is that the
interface between HyperCard and the database can get awkward. On the other hand, they
do greatly improve the data handling abilities of HyperCard.
HyperHIT Product Family
But one database engine gives you the ease of HyperCard and the power of
databases. It is HyperHIT, which was developed by Griffin Software, Inc. and is
published by SoftStream International, Inc. The HyperHIT product line actually
contains three database products to meet different design needs; they are HyperHIT,
HyperHIT-R and HyperHIT-N.
A Hierarchical Database: HyperHIT
HyperHIT is the original product. It is based on a hierarchical database model.
The keys are text keys that can be up to 128 characters in length. You can have multiple
sets of keys (keysets) and you can define the set of keys as being ASCII, International,
number or date, to ensure that they will be sorted in the order that you want.
Each key can point to both a record and another keyset. By allowing the key to
point to another keyset you can build a hierarchy of keys. Each key can point to only
one keyset, but the keyset can have up to 32K keys pointing to it.
Records can be either text, sounds (snd ) or pictures (PICT). You do not define
fields for the record, but maintain that within your scripts. This allows you to use
HyperCard’s chunking expressions to delimit fields. Typically, returns are used as
field delimiters so that line 1 is field 1, line 2 is field 2, etc.
HyperHIT has the advantage of being very flexible. Through your scripting you
can create enormously complex databases with very complicated structures. It has the
disadvantage of placing the burden of maintaining the database structure on the
scripter. In other words, be prepared to do some thinking through and studying before
you build a database with HyperHIT.
A Relational Database: HyperHIT-R
Since a lot of HyperCard users were willing to give up the flexibility of
HyperHIT for an easier-to-use database, we developed another product called
HyperHIT-R. This is based on the relational database model.
With HyperHIT-R, you define tables, or relations, by defining the fields that
will exist in the relation. You can define multiple tables per database file (collection),
to allow you to keep all related data in one physical file. As in HyperCard, all fields are
actually stored as text fields, but by defining the field type, you indicate how
comparisons are made on those fields. For example, if a field is defined as a number
field, then “1.00” is equal to “1”; but if you define a field as a text field, then “1.00”
is not equal to “1”. Fields in HyperHIT-R may be text, number, date or logic.
HyperHIT-R also maintains the field delimiters, which allows you to extract
fields by name. In other words, it is easy to use. By the way, the HyperHIT-R package
also includes a copy of HyperHIT. (We’ll tell you why at the end of this article.)
A major strength of HyperHIT-R is the way it supports complex search criteria,
automatically optimizing on an indexed field if one exists. The following is an example
of such a query:
(HHIT Zip >= “60000” And HHIT Zip <= “69999”) and
(HHIT LastName Starts_With cd fld lastInitial)
A Multi-User Database: HyperHIT-N
HyperHIT-N is the third member of the HyperHIT family. It is simply the
network version of HyperHIT and HyperHIT-R. It consists of a server application and
network versions of the XCMDs. All of the HyperHIT and HyperHIT-R commands are
supported, with appropriate record-locking extensions. The HyperHIT Server can run
in the background under MultiFinder and, unless you have an extremely old Mac Plus,
you can run a HyperCard client in the foreground at the same time.
Let Us Show You How This Works
We recently discussed an application with a staff member at a city zoo. He
wanted to develop a database that would let zoo visitors request facts about various
animals such as their habitat, family, markings, etc., and be able to do look-ups based
on these attributes.
While we will not attempt to completely cover all of the application design, we
will try to show how such an application can be developed using the HyperHIT database
engine.
We want to keep the following information about each animal:
Field Type Contents
Name Text Common name of the animal.
Species Text Latin species name.
Genus Text Latin genus name.
Family Text Latin family name.
Habitat Text Environment where animal is normally found.
Continent Text Region of the world where animal is found.
Markings Text Colorings unique to the species.
Diet Text Normal diet for animal.
Relatives Text Return separated list of related species.
Let’s jump right into some scripting. The following script is all that is needed to
create the initial database:
--1
on InitDatabase
global db
Put "HyperHIT" into db
CreateCollection "db
CreateRelation "db","Animals
CreateField "db","Animals","Name","Text
CreateField "db","Animals","Species","Text
CreateField "db","Animals","Genus","Text
CreateField "db","Animals","Family","Text
CreateField "db","Animals","Habitat","Text"
CreateField "db","Animals","Continent","Text
CreateField "db","Animals","Markings","Text
CreateField "db","Animals","Diet","Text
CreateField "db","Animals","Relatives","Text
CreateIndex "db","Animals","Name",20
CreateIndex "db","Animals","Family",20
end InitDatabase
With every HyperHIT database you must declare a global variable and initialize
it with the word “HyperHIT”. HyperHIT uses this global variable to keep all the data it
needs to manage the database. Since HyperCard expects only text to be kept in a
variable, HyperHIT stores a handle to the actual data block in this global variable.
Global Variables
At this point we need to explain about HyperCard, global variables and XCMDs.
Those of you who have written handlers in HyperTalk know that HyperCard treats
parameters as local variables. That is, they exist within the handler, but do not exist
once the handler is completed. The same is true of XCMDs. Any parameters that are
passed to the XCMD are disposed of when the XCMD completes. So you cannot pass a
variable to an XCMD and have it change the value of that variable, as you can in other
languages.
An XCMD can, however, get or change the value of a global variable if it knows
the name of the global variable. This means that we can pass a variable to an XCMD and
have it change the variable’s value, by passing the name of the global variable to the
XCMD. Kind of convoluted, but it works.
This is the reason that all the HyperHIT commands require the name of a global
variable as the first parameter. It would have been easy for us to hard-code in a global